Developers of many application programs (“applications”) implement the applications so that they can be customized by third parties. To customize an application, a third party develops custom code (e.g., add-ins and document-level customizations) that uses functionality exposed by the application. The custom code may improve the usability of the applications or provide additional functionality (e.g., domain-specific functionality). Such applications are referred to as “host applications” because the custom code is hosted within the process of the application. Developers of applications typically want to encourage the development of custom code for their applications to increase the demand for their applications. As a result, such developers may provide “runtimes” that facilitate the development of custom code. A runtime is code that is loaded along with custom code and provides services to the custom code. These services may include higher-level functionality than exposed by the application or may include domain-specific functionality. When an application is to load and start the execution of custom code, the application may load the runtime and direct the runtime to load and start the execution of the custom code.
Because of the ease of developing custom code as “managed code,” many applications support the execution of custom code in the .NET Framework provided by Microsoft Corporation. The .NET Framework provides a common language runtime (“CLR”) that provides high-level operating system type services to the managed programs (including custom code and applications) and serves as an execution engine for managed programs. The CLR ensures that managed programs do not take any unauthorized action. As such, the CLR acts as a “sandbox” within which managed programs execute. The CLR provides application domains (“appdomains”) in which different managed programs can execute to help ensure that an errant managed program will not unduly affect the execution of another managed program.
The Microsoft Office suite of applications introduces a new user interface called the Ribbon. The Ribbon replaces menus and toolbars in several Office applications. The Ribbon provides an XML/callback model that allows developers to create a custom Ribbon user interface for Office documents and applications by extending the standard Ribbon user interface. The XML/callback model requires a developer to generate an XML document that describes the custom user interface. Table 1 illustrates a sample XML document describing a custom user interface.
TABLE 1 1.<customUIxmlns=“http://schemas.microsoft.com/office/2006/01/customui”> 2.<ribbon> 3.<tabs> 4.<tab id=“Tab1” label=“Tab1”> 5.<group id=“Group1” label=“Group1”> 6.<button id=“Button1”onAction=“Button1_OnAction”label=“Button1” /> 7.</group> 8.</tab> 9.</tabs>10.</ribbon>11.</customUI>Lines 1 and 11 are “customUI” tags that delimit the description of the user interface. Lines 2 and 10 are “ribbon” tags that delimit the description of the Ribbon elements to extend the Ribbon. Lines 3 and 9 are “tabs” tags that delimit the description of multiple tabs of the extended user interface. Lines 4 and 8 are “tab” tags that delimit the description of a tab. The described tab has an “id” of “Tab1 ” and a label of “Tab1 ” as attributes. Lines 5 and 7 are “group” tags that delimit the description of a group within the tab. The described group has an “id” of “Group1 ” and a label of “Group 1 ” as attributes. Line 6 is a “button” tag that defines a button within a group. The button has an “id” of “Button1,” an “on Action” of “Button1_OnAction,” and a label of “Button1 ” as attributes. The extended user interface thus has one tab with a group that contains one button. When a user takes some action directed to (e.g., clicks on) “Button1,” the Office application calls back to the add-in using the IDispatch interface of Microsoft's Component Object Model (“COM”) passing an indication of “Button1_OnAction.” The add-in can then handle the user action as appropriate.
Table 2 illustrates code generated by a developer using the XML/callback model to extend a Ribbon user interface.
TABLE 21.{2. [ComVisible(true)]3. public class Ribbon : Office.IRibbonExtensibility4. {5.  private Office.IRibbonUI ribbon;6.7.  public Ribbon( )8.  {9.  }10.11.  public string GetCustomUI(string ribbonID)12.  {13.   return GetResourceText(“ExcelAddIn3.Ribbon”);14.  }15.16.  public void OnLoad(Office.IRibbonUI ribbonUI)17.  {18.   this.ribbon = ribbonUI;19.  }20.21.//Button On_Action Callback22.  public void Button1_OnAction(Office.IRibbonControl control)23.  {24.    MessageBox.Show(“Hello World”);25.  }26.27.  private static string GetResourceText(string resourceName)28.  {29.   Assembly asm = Assembly.GetExecutingAssembly( );30.   string[ ] resourceNames = asm.GetManifestResourceNames( );31.   for (int i = 0; i < resourceNames.Length; ++i)32.   {33.    if (string.Compare(resourceName, resourceNames[i],StringComparison.OrdinalIgnoreCase) == 0)34.    {35.     using (StreamReader resourceReader = newStreamReader(asm.GetManifestResourceStream(resourceNames[i])))36.     {37.      if (resourceReader != null)38.      {39.       return resourceReader.ReadToEnd( );40.      }41.     }42.    }43.   }44.   return null;45.  }46.47. }48.}Line 3 indicates that the class Ribbon implements the IRibbonExtensibility interface. The IRibbonExtensibility interface includes a GetCustomUI function. When an Office application initially loads an add-in, it requests the IRibbonExtensibility interface from the add-in. The Office application then calls the GetCustomUI function to retrieve the XML string describing the extended user interface. The Office application also calls an OnLoad function, which is defined by the top level XML element—customUI, to provide an IRibbonUI interface to the add-in. Lines 11-14 illustrate that the GetCustomUI function implemented by a developer invokes a GetResourceText function to retrieve the XML file to return to the Office application. Lines 16-19 illustrate that the OnLoad function implemented by a developer stores a reference to the IRibbonUI interface passed by the Office application. The IRibbonUI interface includes an InvalidateControl function for notifying the Office application that a component of the extended user interface has been modified (e.g., a new label has been defined for a button). Lines 21-25 illustrate the “Button1_OnAction” callback method. When a user performs some action directed to “Button1,” as described in Table 1, the Office application invokes the Invoke function of the IDispatch interface passing as a parameter “Button1_OnAction.” The Invoke function then invokes the method of lines 21-25. The Office application retrieves a reference to the IDispatch interface by invoking the QueryInterface function of the (Unknown interface of the COM model. Lines 27-44 illustrate an implementation of the GetResourceText function. The GetResourceText function is one way that the GetCustomUI function may return the XML string. The GetCustomUI function may alternatively return the XML string in another manner.
This XML/callback model for Ribbon customization, which requires creating an XML document and constructing callback methods, may not be familiar or intuitive to all developers. In particular, the XML/callback model for Ribbon customization is not intuitive to developers familiar with standard .NET programming. The .NET programming experience is generally characterized by utilization of a class library, operating on objects through properties and events, and other features.